Graphical user interface for tracking data access and data changes in a centralized database

ABSTRACT

Embodiments provide a method, including: receiving a request to create a new document identifying an intended state of use for the new document; accessing, from a web-based data repository, a plurality of modules for the document type; populating the new document using the plurality of modules; accessing at least one modifiable module having default parameters intended for use within a section of the new document and modifiable for the intended state of use; modifying the at least one modifiable module based upon indication of a gap between the at least one modifiable module and the intended state of use, wherein the gap is determined based on the laws and regulations of the selected intended state of use, wherein the modifying comprises incorporating the information related to the gap into the modifiable module; and finalizing the new document by inserting the modified module into the section of the new document.

BACKGROUND

Large corporations, for example national insurance providers, recreatecertain documents (e.g., contracts, policy information, invoicerequests, etc.) repeatedly during the course of normal business.Generally, these documents are created using language that is specificto the current implementation. For example, states have varying lawsregarding business practices within their jurisdiction, thus contractlanguage can vary greatly based on the law of the state where thecontract is formed.

Therefore, large corporations, especially those operating acrossmultiple states or countries are subject to an overwhelming amount ofgovernmental regulations. These regulations are typically extremelyspecific, difficult to comprehend, and vary in minute but significantways from jurisdiction to jurisdiction. Thus, it can be difficult for anentity, even a large corporation, to manage the overwhelming amount ofjurisdictional specific information as well as ensuring they areutilizing the current regulations.

In addition to the variability based on jurisdiction, the language usedto create these documents is put through a rigorous vetting process thatensures they are accurate and complete in nature. This process mayinvolve many iterations and revisions of the language and may involvedifferent individuals (e.g., drafter, legal counsel, state regulator,etc.). Because of the vastness of the information, and the frequencywith which the information may be updated from different sources keepingall of the information centralized is of vital importance.

BRIEF SUMMARY

In summary an embodiment provides a method, comprising: receiving, at agraphical user interface, a request from a user to create a new documenthaving a document type, wherein the request identifies an intended stateof use for the new document; accessing, from a web-based data repositorystoring modules corresponding to portions of a document, a plurality ofmodules for the document type; populating the new document using theplurality of modules for the document type; accessing, from theweb-based data repository, at least one modifiable module having defaultparameters intended for use within a section of the new document andmodifiable for the intended state of use; modifying the at least onemodifiable module based upon user input received at the graphical userinterface, wherein the user input comprises indication of a gap betweenthe at least one modifiable module and the intended state of use,wherein the gap is determined based on the laws and regulations of theselected intended state of use, wherein the gap identifies a differencebetween requirements included in the at least one modifiable module andrequirements of the selected intended state of use of the first languagemodule and wherein the modifying comprises incorporating the informationrelated to the gap into the modifiable module for insertion into the newdocument; finalizing, using the modified at least one modifiable module,the populated new document by inserting the modified at least onemodifiable module into the section of the new document; and displaying,at the graphical user interface, the finalized new document.

An additional embodiment provides an apparatus, comprising: a processor;and a non-transitory computer readable storage medium having computerreadable program code embodied therewith and executable by theprocessor, the computer readable program code comprising code configuredto: receive, at a graphical user interface, a request from a user tocreate a new document having a document type, wherein the requestidentifies an intended state of use for the new document; access, from aweb-based data repository storing modules corresponding to portions of adocument, a plurality of modules for the document type; populate the newdocument using the plurality of modules for the document type; access,from the web-based data repository, at least one modifiable modulehaving default parameters intended for use within a section of the newdocument and modifiable for the intended state of use; modify the atleast one modifiable module based upon user input received at thegraphical user interface, wherein the user input comprises indication ofa gap between the at least one modifiable module and the intended stateof use, wherein the gap is determined based on the laws and regulationsof the selected intended state of use, wherein the gap identifies adifference between requirements included in the at least one modifiablemodule and requirements of the selected intended state of use of thefirst language module and wherein the modifying comprises incorporatingthe information related to the gap into the modifiable module forinsertion into the new document; finalize, using the modified at leastone modifiable module, the populated new document by inserting themodified at least one modifiable module into the section of the newdocument; and display, at the graphical user interface, the finalizednew document.

A further embodiment provides a computer program product, comprising: anon-transitory computer readable storage medium having computer readableprogram code embodied therewith, the computer readable program codeexecutable by a processor and comprising: computer readable program codethat receives, at a graphical user interface, a request from a user tocreate a new document having a document type, wherein the requestidentifies an intended state of use for the new document; computerreadable program code that accesses, from a web-based data repositorystoring modules corresponding to portions of a document, a plurality ofmodules for the document type; computer readable program code thatpopulates the new document using the plurality of modules for thedocument type; computer readable program code that accesses, from theweb-based data repository, at least one modifiable module having defaultparameters intended for use within a section of the new document andmodifiable for the intended state of use; computer readable program codethat modifies the at least one modifiable module based upon user inputreceived at the graphical user interface, wherein the user inputcomprises indication of a gap between the at least one modifiable moduleand the intended state of use, wherein the gap is determined based onthe laws and regulations of the selected intended state of use, whereinthe gap identifies a difference between requirements included in the atleast one modifiable module and requirements of the selected intendedstate of use of the first language module and wherein the modifyingcomprises incorporating the information related to the gap into themodifiable module for insertion into the new document; computer readableprogram code that finalizes, using the modified at least one modifiablemodule, the populated new document by inserting the modified at leastone modifiable module into the section of the new document; and computerreadable program code that displays, at the graphical user interface,the finalized new document.

Additional embodiments are described, including other methods, as wellas devices/apparatuses, systems including multiple devices, andproducts.

The foregoing is a summary and thus may contain simplifications,generalizations, and omissions of detail; consequently, those skilled inthe art will appreciate that the summary is illustrative only and is notintended to be in any way limiting.

For a better understanding of the embodiments, together with other andfurther features and advantages thereof, reference is made to thefollowing description, taken in conjunction with the accompanyingdrawings. The scope of the invention will be pointed out in the appendedclaims.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates an example of the formation of a final documentthrough the use of modules and sections.

FIG. 2 illustrates an example of creating a new blank filing.

FIG. 3 illustrates an example of generating a filing through data entry.

FIG. 4 illustrates an example of selecting a desired module.

FIG. 5A illustrates an example of modification selection.

FIG. 5B illustrates another example of modification selection.

FIG. 6 illustrates an example of gap creations.

FIG. 7 illustrates an example of the module that will be created.

FIG. 8 illustrates an example of the module in its original state.

FIG. 9 illustrates another example of module modification.

FIG. 10A illustrates an example of a search query function.

FIG. 10B illustrates another example of a search query function.

FIG. 11 illustrates an example of end user access to the moduledatabase.

FIG. 12 illustrates an example system for utilizing a graphical userinterface for tracking data access and data changes in a centralizeddatabase.

FIG. 13 illustrates an example method of utilizing a graphical userinterface for tracking data access and data changes in a centralizeddatabase.

DETAILED DESCRIPTION

It will be readily understood that the components of the embodiments, asgenerally described and illustrated in the figures herein, may bearranged and designed in a wide variety of different configurations inaddition to the described example embodiments. Thus, the following moredetailed description of the example embodiments, as represented in thefigures, is not intended to limit the scope of the embodiments, asclaimed, but is merely representative of example embodiments.

Reference throughout this specification to “one embodiment” or “anembodiment” (or the like) means that a particular feature, structure, orcharacteristic described in connection with the embodiment is includedin at least one embodiment. Thus, the appearance of the phrases “in oneembodiment” or “in an embodiment” or the like in various placesthroughout this specification are not necessarily all referring to thesame embodiment.

Furthermore, the described features, structures, or characteristics maybe combined in any suitable manner in one or more embodiments. In thefollowing description, numerous specific details are provided to give athorough understanding of embodiments. One skilled in the relevant artwill recognize, however, that the various embodiments can be practicedwithout one or more of the specific details, or with other methods,components, materials, et cetera. In other instances, well knownstructures, materials, or operations are not shown or described indetail to avoid obfuscation.

An embodiment addresses the issues of large scale information collectionand maintenance. As will become more apparent in the description ofexample embodiments, the discussed technological improvements offered bythe various embodiments are applicable to a large variety of companiesthat use or maintain a large quantity of documentation that may berequired to be reproduced while also accommodating small variations inthe documentation, e.g., Fortune 500 companies, across all verticalsegments.

Although various example embodiments are described with a focus oninsurance enterprise applications, e.g., insurance filings andcontracts, the principles and technological improvements offered maylikewise be applied to various applications, e.g., of transportationcompanies, manufacturing companies, etc. Thus, embodiments permitenterprises, particularly large enterprises, to improve the creation andlifecycle management of information modules (e.g., paragraphs,sentences, phrases, verbiage, etc.). Embodiments may also be applied incontexts other than reproduced legal documents for large corporations(e.g., form letters for advertising purposes, newsletter distribution,article creation, etc.).

As mentioned, it is typical for corporations to recreate certaindocuments during the course of regular business. Because of thevariation in these documents, the total number and scope of thesedocuments can become difficult to manage. Thus, a system is needed tomanage these variations (e.g., jurisdiction based modules) and allow forease in searching (e.g., by keyword, module number, module name, etc.)and tracking. Not only can there be a broad range of repetitiveinformation, but the information may need minor or large modificationsin order to meet the needs of a particular issue. Traditionally,insurance companies have drafted these types of insurance contractdocuments with conditional logic (e.g., if/then statements) to generatecontract language that complies with the insurance regulations of eachof the states where the contract may be issued.

However, this method is inefficient and overly burdensome, and the useof conditional logic in legal documents can create future issues andmake it difficult to amend or revise particular sections of the documentwithout causing a cascading affect and negatively impacting otherportions of the document thereby causing unintended consequences. Thisis particularly a problem regarding insurance contract documents, whichcould contain conditional logic across hundreds of sections. Thus, achange to a single section could cause a chain effect creating issuesthroughout the remainder of the document. This can be a particularproblem when a jurisdiction updates or modifies their regulations andstandards. Thus, a solution is needed to manage and track thecomponents/modules of a contract.

Additionally, because legal documents can be extremely large and mayrequire changes to individual sections based on the intendedjurisdiction (e.g., states often require that an insurance policycontract form be filed with and approved by the state's insurancedepartment), they need to be broken down into a system of modules. Thesemodules may be recombined to create whole documents. This allows for agranular system of document creation, where an end user can select therelevant and approved portions of a document and combine them to formthe final required document. Therefore, a system is needed that canmaintain not only a single module in a variety of iterations (e.g., adisability insurance policy for each state based on that state's laws),but many modules in varying iterations that may later be combined toform various documents.

Moreover, the creation of the documents from conception of the genericform to the final stage may consist of multiple iterations of multiplemodules and needs to be tracked and monitored. This process of approvaland modification likely involves many different individuals in differentroles who each only require a particular type of access (e.g., anadministrator, legal department, sales department, IT department, etc.).Thus, an embodiment provides a solution that cannot only manage thelarge number of individual modules, but also their revision andmodification history. Because of the vastness of the information, andthe fact that the information may be updated from difference sources(e.g., different employees at a company) the centralization andmaintenance of the data is critical.

In order to address the above discussed issues, an embodiment utilizes aweb based repository that assists product delivery with managingfilings, approved language, objections, and gaps. Each of thesecategories contains their own issues and complexities, which createstechnical issues regarding the management and implementation required tokeep them all organized in a complete and continuous fashion. Anembodiment also provides the business area (e.g., operations, sales,distribution, underwriting, product, compliance, etc.) with approvedlanguage variability by product in the context of a document.

An embodiment needs to improve the overall process discussed herein,enhance reporting and analysis and allow quick access/reference of themost recent approved or changed modules. Thus, an embodiment provides aclear articulation of state requirements in the context of legaldocuments (e.g., contract, filing, etc.); houses all the modules in eachiteration type (e.g., state specific and generic); identifies andupdates the understanding of variability allowed in the fillabledocuments.

Embodiments represent a significant technical improvement to thelifecycle management of language modules through an enhanced graphicaluser interface (GUI) implementation. An embodiment is directed tosubstantially more than merely a computer implementation of a routine orconventional activity previously known in the industry as itsignificantly advances the technical efficiency, access and/or accuracyof creating, maintaining, tracking, and storing jurisdictional specificlanguage modules by implementing a specific new method and system asdefined herein.

An embodiment provides a specific advancement in the area of languagemodules management for large companies (e.g., a large insurancecompany), by providing technical benefits for module creation, modulevariability, module lifecycle, and module implementation and suchadvances are not merely a longstanding commercial practice. Theembodiments provide improvement beyond a mere generic computerimplementation as they involve the processing and conversion ofsignificant amounts of data in a new beneficial manner as well as theinteraction of a variety of specialized insurance, client and/or vendorsystems, networks and subsystems.

For example, an embodiment facilitates the efficient management of acentralized and intuitive module repository. By managing and trackinglanguage modules from conception to final approval the embodiment fillsan immediate and longstanding need for large corporations. In addition,the repository allows for gaps to be identified by a particularindividual or application. The gapping process (e.g., modifying ageneric language module to accommodate a particular jurisdiction) isalso managed and tracked in a sophisticated and efficient manner. Forexample, different individuals are involved at different states of theprocess; however the work process is smooth and fluid during each phaseof the transition.

This fluidity is attained because an embodiment stores all theinformation in a centralized database. Thus there is no need formultiple iterations of the module, and no way for confusion regardingwhich module is the most current or if a certain module is approved. Inaddition, an embodiment manages each user's access level. Certain userswill have greater access than others. This eliminates the possibilitythat a user could modify a portion of the modules, section, or documentthat they are not qualified or approved to modify. This reducesaccidents and mistakes caused by user error.

The illustrated example embodiments will be best understood by referenceto the figures. The following description is intended only by way ofexample, and simply illustrates certain example embodiments.

Referring to FIG. 1, illustrates how modules may be stored in aweb-based repository for managing modules/components of a contract. Thegeneral concept of document creation through the use of modules is shownat 100. Typically, a final document (e.g., an insurance contract) at 110will follow a certain pattern of formation even across multiplejurisdictions. For example, the introduction and explanation portions ofthe document may be very similar in each state because they containlittle substantive law regarding the jurisdiction. This allows for thecreation of sections at 120-150 relevant to the required needs of thedocument. The illustrated example shows that a document may containmultiple sections up to and including section N at 150. N as used hereinrepresents an integer corresponding to the number of required sectionsin the final document 110.

As discussed herein, once a particular document 110, section 120, ormodule 121 is approved (e.g., through the internal company process orthe jurisdictional process) it is stored in module format to allow forgranular implementation. This information is used by the technology teamto document system requirements for the document creation system asdiscussed herein to allow for the stored modules 121-123, 131-133,141-143, 151-153, to be combined to form individual sections, which thenform a final document 110. For example, section 1 at 120 may requiremodule 1.1, 1.5, 1.78, 1.88-1.120, and 1.154. Once each required sectionis composed based on the approved modules. Therefore, it is importantnot only to store each module with clearly distinguishablecharacteristics (e.g., name, number, jurisdiction, etc.), but toassociate the specific module with the respective section and document.

Referring to FIG. 2, an embodiment provides a system for conducting asearch of existing filing documents or creation of a new filing at 200.For example, a user enters the name of a desired filing document ormodule at 201, and clicks the search button at 202. Features regardingthe ability to search are discussed in further detail herein,specifically FIG. 10. Alternatively, if a user desires to create a newfiling the “new filing” button is selected at 203.

If the “new filing” button is selected at 203, an embodiment, displaysthe filing creation page (e.g., the drafting details page at 300 in FIG.3). Referring now to FIG. 3, once an embodiment is at the filingcreation page, the new filing may be named at 301. This naming may allowfor easy identification and improves the subsequent search capability.In addition to a name, a tracking number may be entered at 302, a filingtype can be selected at 303, and the intended state (e.g., Virginia,Colorado, etc.) of use may be selected at 304. These selections are usedto identify the state specific requirements that will affect the finallanguage of the filing. Additionally, the state selection is used forthe gap analysis and state specific modifications discussed herein.

An embodiment may also allow for a selection of the coverage type at 305and a particular project association at 306. In addition to state andjurisdictional restrictions, some modules may be market class specific(e.g., employee, association, etc.) at 307. Additionally, the filingcompany can be selected at 308 and the reason for drafting at 309.Further beneficial information may be entered such as if a vendor isinvolved in the filing at 310, is a Statement of Variable Language(SOVL) being filed as part of the new filing at 311, and is the filingexempt at 312. It may also be benefit the tracking and management of thenew filing to know if there are any related filings at 313 and if thereare related filings the logs should be copied over to the new filing at314.

Because jurisdictional regulations are constantly in flux, it may bethat the new filing is in response to a regulatory alert indicating arecent change in a state's regulatory scheme that needs to be addressed.The new filing can be flagged as being in response to a regulatory alertat 315. Once all of the information is entered, a new filing can becreated by clicking the “add filing” button at 316. Thus extensivecollection of data is used to enhance the management and trackingcapabilities as the prospective filing moves through the system.

Referring now to FIG. 4, in an embodiment, once a filing is created themodifying and tracking may begin. In order to minimize possible errors,detailed information regarding the filing (e.g., name, market, program,etc) is shown at the top of the display at 410. In addition to thisinformation, an embodiment may also display the date and time of thelast revision cycle and the individual that made the revision as shownat 420. This allows for a quick glance review of the filing to ensurethat the user has correctly accessed the desired filing, and alsoinforms the user of when the last modification took place, and who itwas modified by.

As discussed previously herein, the creation of a document requires thatmodules be combined into sections and those sections be combined intofinal documents. Thus, a way to modify, compose, and remove each ofthese is required. As shown at 400, the user has the option to selectwhich documents 430, sections 440, and modules 450, requiremodification. In an embodiment, once a user selects a particulardocument at 430 associated with the filing, a listing of sections isdisplayed at 440. The selection of a section further narrows the user'sdesired language to be modified and a list of modules are displayed at450. The user can then select individual modules to add, modify, orremove based on the document needs at 460. Through this system, eachmodification can be tracked individually and accorded a time stamp andidentify the user implementing the modification.

Thus, if subsequent issues arise, each creation, modification, anddeletion action can be tracked to a particular time and a particularuser responsible, which may give a better understanding of the processand decision making behind the action. In addition to the detailsdiscussed above, a database of gaps is also maintained regarding eachfiling.

Referring now to FIG. 5A, an embodiment tracks the gaps of a filing andallows user modification of those gaps. As discussed in FIG. 4, thedetailed information regarding the filing (e.g., name, market, program,etc) is again shown at the top of the display 500A as well as the date,time, and author of the last revision cycle at 510A. FIG. 5A shows thegap log prior to any selection being made. An embodiment may, as shownin FIG. 5A, not show section or module information at 530A and 540Auntil a document selection is made at 520A.

Referring now to FIG. 5B, once the desired documents, sections, andmodules are selected at 500B (e.g., POI, Face Page, Form GDB-2400N/A—Face Page—Face Page) additional modification options becomeavailable. For example, after a module is selected a gap may be added byselecting “add gap” at 510B. Selecting “add gap” at 510B will open theGap Details tab as shown in FIG. 6. In addition to adding a gap, a usermay send a gap to quality assurance at 520B. In an embodiment, gaps maybe quality control checked within the corporation or organization beforemoving forward in the process (e.g., being sent to a state regulatoryagency for approval).

Depending on a user's authorization (e.g., whether they are anadministrator, sales, IT, etc.) other options are also availableregarding gaps. For example, someone with approval authority (e.g., anattorney for legal contracts) may review the submitted gap language andapprove it to progress in the process by clicking “checked gaps QAcompleted” at 530B. Alternatively, if person with approval authority isunsatisfied, they may select the particular module(s) and click the“checked gaps objected to” at 540B. The gaps that are objected to wouldthen be re-modified and revised again according to the direction of theapproving entity.

Referring now to FIG. 6, after as discussed above, “add gap” isselected, the gap details tab is displayed. Various characteristics canbe assigned to a gap in the gap details screen at 600. For example, anembodiment, may allow a user to select the gap origin (e.g., regulatoryalert, approval objection, statutory or regulatory changes, etc.) at610. Additional options are also available, such as defining a changereason at 620 and entering comments or instructions. For example, toassist the Information Technology Business Analysts with determiningrequirements at 630 and to help users understand the reason for the gapchange at 640. Once the all the relevant details are entered fortracking purposes, a gap can be added at 650.

Referring now to FIG. 7, once a gap has been created as described inFIG. 6, module information must be defined for the gap. Based on theselections made during the gap log process (e.g., FIGS. 5A and 5B),various elements within the “new modules details” tab may be prefilledat 700. In an embodiment, the pre-filled selections can be modified by auser if required via a drop down or data entry box.

Referring now to FIG. 8 and FIG. 9, in an embodiment, once a gap iscreated, a user can view the original language at 800. The original orgeneric module language which is stored in the database is automaticallypre-filled due to the previous modules selection at 810. In anembodiment, when it is determined that a gap exists, and thus amodification is required, a new language display at 900 is used tomodify the language. In an embodiment, a user may enter red-lined textinto the change description data field at 910. This allow for easierrecognition of the gapping update at a later time. Additionally, a usermay enter a clean copy of the updated module language once the change isimplemented at 920.

In an embodiment, if it is determined that the requested change is partof the SOVL of all of the states' insurance contract documents using theaffected generic section or module, then the new SOVL tab is selected at940. The new SOVL tab is similar to the new language tab in that it hasa change description 910 and clean language 920 data field. A SOVL is adocument which typically lists variable text that has been approved by aregulator. A non-limiting example of variable text is the use of theterm employee, associate and colleague to refer to someone who wouldcommonly be called an employee.

Referring now to FIGS. 10A and 10B, in an embodiment, a filing searchcan be conducted at 1000A. For example, a member of the product deliveryteam could access the centralized database via a web portal and enter aterm or phrase to be searched at 1010B. The user may then press thesearch button at 1020B to conduct a search of the database. Anembodiment returns possible matches for the user to view in 1000B. Inthe present example, the user searched for “msp” as shown at 1010B. Thissearch resulted in retrieval of a filing with a related title at 1020B.Once the search results are returned, a selection can be made based onthe desired filing (e.g., clicking “select filing” at 1030B). Once thefiling is selected, the drafting details tab (similar to that shown inFIG. 3 is opened and the filing information is pre-filled.

Once the gaps have been addressed (e.g., the modules have been updatedand approved) an embodiment stores the modules in a database server suchas that shown at 1110 in FIG. 11 and discussed herein. This databaseserver can be maintained independently by a third party (e.g., cloudserver service) or stored and maintained in house. Although a singlesystem is shown, it is intended as a non-limiting example of possibleimplementations. Those skilled in the art will recognize that multipledatabases on multiple systems may be utilized to house the plurality ofmodules. For example, in an embodiment, the systems may breakdown alongcategorical lines (e.g., by jurisdiction, module type, etc.).

In an embodiment, the database is connected to a network using a networkconnection device such as, for example, 1205 of FIG. 12. The connectiondevice may connect to a local area network (LAN) or a wide area network(WAN) at 1160. This allows multiple end users at 1120-1150, to accessthe module database, make module selections, and update the modules. Byway of specific example, an end user 1120-1150 may operate his or hersystem to compile and send data relating to a plurality of parameters,e.g., state or other jurisdictional information, data relating to thetype of coverage(s) needed, and the like. The end user systems 1120-1150may send this data via a network, e.g., network 1160, such that it isreceived by a database server that stores modules, e.g., database server1110. Database server 1110, for its part, receives the data parameterssent by an end user system, e.g., 1120, and processes the dataparameters to identify specific modules that are requested. The databaseserver 1110 then may export these modules to the requesting end usersystem, e.g., 1120. The database server 110 moreover may compile themodules, e.g., into a partially complete or complete document, accordingto the data parameters received, prior to transmitting the same over thenetwork, e.g., 1160, to the requesting client system, e.g., 1120.

Additionally or alternatively, a secondary system (e.g., a documentcreation application server) may access the database and create thedocuments. The secondary system may then pass the completed documents tothe end user systems 1120-1150 for distribution a product delivery teamor equivalent. In an embodiment, this secondary system may be a standalone application, or alternatively built into the document repositoryfor ease in document creation.

The graphical user interface for tracking data access and data changesin a centralized database may be implemented in an automated or semiautomated system using appropriate circuitry and components programmedaccording to the various embodiments. While various other circuits,circuitry or components may be utilized in computing devices utilizedfor such special purposes, an example illustrated in FIG. 12 includes asystem design found for example in laptop, desktop or other computingplatforms. Such circuitry 1200 may be used in a device that implements ahigh availability scoring methodology, portfolio prioritization andtesting process, as described herein, such as a computing device of aninsurance carrier used for enterprise application portfolio management.

In the example of FIG. 12, a storage device 1220 includes software suchas a module management system program 1212 that may be run or executedby processor(s) 1210 according to an operating system 1222. Thecircuitry 1200 provides that the processor loads the operating system1222 and thereafter the application program 1210, e.g., into memory1230.

System 1200 typically includes a network interface 1205 facilitatingcommunications with other devices, e.g., a connection to other devicesover a network 1250 using components such as a WWAN transceiver, a WLANtransceiver or a wired connection, e.g., a LAN connection. Commonly,system 1200 will include an input/output controller 1240 for data inputand display. System 1200 typically includes various memory 1230 andstorage devices 1220, for example a database 1224, e.g., for storingmodules and gap data, referred to herein.

Device circuitry, as for example outlined in FIG. 12, may be used byinsurance carriers for tracking data access and data changes in acentralized database. It will also be apparent that circuitry other thanthe non-limiting example outlined in FIG. 12 may be used.

By way of example, FIG. 13 illustrates an example method of a graphicaluser interface for tracking data access and data changes in acentralized database. In an embodiment, a first module is stored in adatabase at 1310. This generic contractual language may later be used asa template for the gapping process that facilitates the creation ofstate specific modules. In order for the modification to take place, auser is authenticated via credentials at 1320. The user is then grantedaccess to all of or a sub-portion of the data base. In addition, theuser's editing rights may be limited by their authentication. Forexample, an administrator may have full read/write access, while aproduct delivery manager may only be able to view the modules. If theuser is not authorized to access the database, then no action is takenat 1330.

Alternatively, if the user is authorized to access at least asub-portion of the database, they are directed to the GUI discussed atlength herein at 1340. Using this GUI, a user can indicate a gap origin(e.g., based on the laws and regulations of the specific jurisdiction)and specify the requirements of the gapping process at 1340. This caninclude selecting a module to be gapped. Based on these specifications,the language module will go through an iterative process where multiplepeople may modify, review, and approve the module for use in a filing.In order to facilitate this process, the modified module (e.g., statespecific contract language) is stored in a database along with thecorresponding gap information at 1350.

Finally, once the module is modified and approved for filing it is thenable to be listed in a searchable database. In addition to the modifiedlanguage, the records of the lifecycle of the module from creation toapproval are associated and stored. Thus, a user can search through theentire repository of modules at 1360. In an embodiment, the search canbe conducted based on a variety of factors (e.g., keyword, modulenumber, module name, etc.).

As will be appreciated by one skilled in the art, various aspects may beembodied as a system, method or device program product. Accordingly,aspects may take the form of an entirely hardware embodiment or anembodiment including software that may all generally be referred toherein as a “circuit,” “module” or “system.” Furthermore, aspects maytake the form of a device program product embodied in one or more devicereadable medium(s) having device readable program code embodiedtherewith.

Any combination of one or more non-signal device(s) may be utilized. Astorage medium may be, for example, an electronic, magnetic, optical,electromagnetic, infrared, or semiconductor system, apparatus, ordevice, or any suitable combination of the foregoing. More specificexamples of a storage medium would include the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), an optical fiber, a portable compact disc read-onlymemory (CD-ROM), an optical storage device, a magnetic storage device,or any suitable combination of the foregoing. In the context of thisdocument, a storage medium is not a signal and “non-transitory” includesall media except signal media.

Program code for carrying out operations may be written in anycombination of one or more programming languages. The program code mayexecute entirely on a single device, partly on a single device, as astand-alone software package, partly on single device and partly onanother device, or entirely on the other device. In some cases, thedevices may be connected through any type of connection or network,including a local area network (LAN) or a wide area network (WAN), orthe connection may be made through other devices (for example, throughthe Internet using an Internet Service Provider), through wirelessconnections, e.g., near-field communication, or through a hard wireconnection, such as over a USB connection.

Example embodiments are described herein with reference to the figures,which illustrate example methods, devices and program products accordingto various example embodiments. It will be understood that the actionsand functionality may be implemented at least in part by programinstructions. These program instructions may be provided to a processorof a general purpose information handling device, a special purposeinformation handling device, or other programmable data processingdevice to produce a machine, such that the instructions, which executevia a processor of the device implement the functions/acts specified.

It is worth noting that while specific blocks are used in the figures,and a particular ordering of blocks has been illustrated, these arenon-limiting examples. In certain contexts, two or more blocks may becombined, a block may be split into two or more blocks, or certainblocks may be re-ordered or re-organized as appropriate, as the explicitillustrated examples are used only for descriptive purposes and are notto be construed as limiting.

As used herein, the singular “a” and “an” may be construed as includingthe plural “one or more” unless clearly indicated otherwise.

This disclosure has been presented for purposes of illustration anddescription but is not intended to be exhaustive or limiting. Manymodifications and variations will be apparent to those of ordinary skillin the art. The example embodiments were chosen and described in orderto explain principles and practical application, and to enable others ofordinary skill in the art to understand the disclosure for variousembodiments with various modifications as are suited to the particularuse contemplated.

Thus, although illustrative example embodiments have been describedherein with reference to the accompanying figures, it is to beunderstood that this description is not limiting and that various otherchanges and modifications may be affected therein by one skilled in theart without departing from the scope or spirit of the disclosure.

What is claimed is:
 1. A method, comprising; receiving, at a graphicaluser interface, a request from a user to create a new document having adocument type, wherein the request identifies an intended state of usefor the new document; accessing, from a web-based data repositorystoring modules corresponding to portions of a document, a plurality ofmodules for the document type; populating the new document using theplurality of modules for the document type; accessing, from theweb-based data repository, at least one modifiable module having defaultparameters intended for use within a section of the new document andmodifiable for the intended state of use; modifying the at least onemodifiable module based upon user input received at the graphical userinterface, wherein the user input comprises indication of a gap betweenthe at least one modifiable module and the intended state of use,wherein the gap is determined based on the laws and regulations of theselected intended state of use, wherein the gap identifies a differencebetween requirements included in the at least one modifiable module andrequirements of the selected intended state of use of the first languagemodule and wherein the modifying comprises incorporating the informationrelated to the gap into the modifiable module for insertion into the newdocument; finalizing, using the modified at least one modifiable module,the populated new document by inserting the modified at least onemodifiable module into the section of the new document; and displaying,at the graphical user interface, the finalized new document.
 2. Themethod of claim 1, further comprising providing a search function at thegraphical user interface.
 3. The method of claim 2, wherein the searchfunction searches the modules based on at least one of: keyword, modulenumber, and module name.
 4. The method of claim 1, wherein the graphicaluser interface includes elements for selecting the at least onemodifiable module to be gapped.
 5. The method of claim 1, furthercomprising pre-filling at least one data field within the at least onemodifiable module based on the indicated gap.
 6. The method of claim 1,further comprising displaying a status of the gap at the graphical userinterface.
 7. The method of claim 1, further comprising releasing anapproved gap as a modified module in response to selection of a gaprelease icon within the graphical user interface.
 8. The method of claim1, further comprising receiving user input comprising user credentials.9. The method of claim 8, further comprising authorizing, based upon theuser credentials, the user before allowing modification of the at leastone modifiable module.
 10. The method of claim 8, further comprisingidentifying, based upon the user credentials, an authorization level ofthe user, wherein the authorization of the user has a plurality ofaccess levels, the levels granting different amounts of access to thedatabase.
 11. An apparatus, comprising: a processor; and anon-transitory computer readable storage medium having computer readableprogram code embodied therewith and executable by the processor, thecomputer readable program code comprising code configured to: receive,at a graphical user interface, a request from a user to create a newdocument having a document type, wherein the request identifies anintended state of use for the new document; access, from a web-baseddata repository storing modules corresponding to portions of a document,a plurality of modules for the document type; populate the new documentusing the plurality of modules for the document type; access, from theweb-based data repository, at least one modifiable module having defaultparameters intended for use within a section of the new document andmodifiable for the intended state of use; modify the at least onemodifiable module based upon user input received at the graphical userinterface, wherein the user input comprises indication of a gap betweenthe at least one modifiable module and the intended state of use,wherein the gap is determined based on the laws and regulations of theselected intended state of use, wherein the gap identifies a differencebetween requirements included in the at least one modifiable module andrequirements of the selected intended state of use of the first languagemodule and wherein the modifying comprises incorporating the informationrelated to the gap into the modifiable module for insertion into the newdocument; finalize, using the modified at least one modifiable module,the populated new document by inserting the modified at least onemodifiable module into the section of the new document; and display, atthe graphical user interface, the finalized new document.
 12. Theapparatus of claim 11, further comprising providing a search function atthe graphical user interface and wherein the search function searchesthe modules based on at least one of: keyword, module number, and modulename.
 13. The apparatus of claim 11, wherein the graphical userinterface includes elements for selecting the at least one modifiablemodule to be gapped.
 14. The apparatus of claim 11, further comprisingpre-filling at least one data field within the at least one modifiablemodule based on the indicated gap.
 15. The apparatus of claim 11,further comprising displaying a status of the gap at the graphical userinterface.
 16. The apparatus of claim 11, further comprising releasingan approved gap as a modified module in response to selection of a gaprelease icon within the graphical user interface.
 17. The apparatus ofclaim 11, further comprising receiving user input comprising usercredentials.
 18. The apparatus of claim 17, further comprisingauthorizing, based upon the user credentials, the user before allowingmodification of the at least one modifiable module.
 19. The apparatus ofclaim 17, further comprising identifying, based upon the usercredentials, an authorization level of the user, wherein theauthorization of the user has a plurality of access levels, the levelsgranting different amounts of access to the database.
 20. A computerprogram product, comprising: a non-transitory computer readable storagemedium having computer readable program code embodied therewith, thecomputer readable program code executable by a processor and comprising:computer readable program code that receives, at a graphical userinterface, a request from a user to create a new document having adocument type, wherein the request identifies an intended state of usefor the new document; computer readable program code that accesses, froma web-based data repository storing modules corresponding to portions ofa document, a plurality of modules for the document type; computerreadable program code that populates the new document using theplurality of modules for the document type; computer readable programcode that accesses, from the web-based data repository, at least onemodifiable module having default parameters intended for use within asection of the new document and modifiable for the intended state ofuse; computer readable program code that modifies the at least onemodifiable module based upon user input received at the graphical userinterface, wherein the user input comprises indication of a gap betweenthe at least one modifiable module and the intended state of use,wherein the gap is determined based on the laws and regulations of theselected intended state of use, wherein the gap identifies a differencebetween requirements included in the at least one modifiable module andrequirements of the selected intended state of use of the first languagemodule and wherein the modifying comprises incorporating the informationrelated to the gap into the modifiable module for insertion into the newdocument; computer readable program code that finalizes, using themodified at least one modifiable module, the populated new document byinserting the modified at least one modifiable module into the sectionof the new document; and computer readable program code that displays,at the graphical user interface, the finalized new document.